[% setvar title Perl6 Summary for the week ending 20020811 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='Perl6 Summary for the week ending 20020811'></a><h1>Perl6 Summary for the week ending 20020811</h1>
<p>Far out in the uncharted backwaters of the unfashionable end of the
Western Spiral arm of the Galaxy lies a small unregarded yellow
sun. Orbiting this at a distance of roughly ninety-eight million miles
is an utterly insignificant little blue-green planet whose
ape-descended life forms are so amazingly primitive that they still
think inventing programming languages is a pretty neat idea.</p>
<p>So, as one amazingly primitive life form to another, here's what's been going
on in Perl 6 development this week. As is becoming tediously
traditional, we'll start with the internals list...</p>
<a name='Array vs. PerlArray'></a><h2>Array vs. PerlArray</h2>
<p>Way back in the mists of a fortnight ago (that's 'two weeks' for the
unenlightened Americans among us.) Melvin Smith announced that he was
thinking about copying some of the fixes that had been made to the
PerlArray PMC over to array.pmc as well. This week, Steve Fink sent in
a patch for an alternative approach, which makes PerlArray a subclass
of Array. Being appropriately lazy, Steve also added some rather
useful looking keywords to the PMC parser, which added some shiny
looking OO features. He then delivered an extended, 3 post monologue
in which he kept replying to himself and refining his explanation of
what the patch did. When he finally stopped talking to himself Dan
told him to just commit it.</p>
<p>A side point in Steve's discussion with himself (and Sean O'Rourke off-list,
apparently) was the idea of dramatically simplifying default.pmc
so it just throws an exception for operations it doesn't know how to
deal with, rather than trying manfully to satisfy the demands of an
unreasonable programmer. Dan reckons he should go ahead and rip out
the old, obsequious code.</p>
<p><a href='http://groups.google.com/groups?selm=20020806202616.GC2114@foxglove.digital-integrity.com' target='_blank'>groups.google.com</a> -- Start here</p>
<a name='Unifying PMCs and Buffers for GC'></a><h2>Unifying PMCs and Buffers for GC</h2>
<p>Mike Lambert had stepped up to this task and gave us a brain dump of
his plans. This week Jerome Vouillon wondered about the long term
plans for the Garbage collector, and wondered if we knew how to
implement a generational garbage collector when one has several
pools. Dan's long term plan for the outside world is that `GC is a
black box that just works.' Internally, he doesn't care, so long as it
satisfies the `just works' criterion. Mike Lambert thinks that a
generational collector shouldn't be too hard.</p>
<p>Josef 'how do I type &quot;&ouml;&quot; again?' H&ouml;&ouml;k wondered how/if
this would affect his matrix implementation, and when/whether his code
would be merged with the current tree. Dan answered that he was a
little concerned about PMCs which add code to the core, and Josef
explained that he wanted to be able to reuse some of the code in some
future multiarray.pmc</p>
<p><a href='http://groups.google.com/groups?selm=20020806133636.GB28828@strontium.pps.jussieu.fr' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=Pine.GSO.4.21.0208050901150.4854-100000@chicken.stacken.kth.se' target='_blank'>groups.google.com</a></p>
<a name='Register allocation for the JIT'></a><h2>Register allocation for the JIT</h2>
<p>Nicholas Clark and Daniel Grunblatt held a learned discussion about
this, with particular reference to the ARM and i386
architectures. There were diagrams. And discussions of hardware
documentation. It was both scary and surprisingly easy to
understand. And a consensus was reached, which is nice.</p>
<p><a href='http://groups.google.com/groups?selm=20020805215944.GB301@Bagpuss.unfortu.net' target='_blank'>groups.google.com</a></p>
<a name='Stack mark ops &amp; such'></a><h2>Stack mark ops &amp; such</h2>
<p>Dan announced that he was `about half a step from putting pushmark,
popmark, stack marks, and suchlike things into the core.' and that
this was everyone's opportunity to tell him what a bad idea it was.
Jerome Vouillon wondered how they'd interact with continuations and
coroutines. Answer: `Interestingly'. Jerome offered a code sample which may be
surprising, and asked Dan a hard question. Which Dan hasn't answered
yet.</p>
<p>Melvin Smith wondered if there was a real issue with continuations,
since each continuation got its own copy of the call stack. There is
an issue, but it'll likely be solved by documenting its existence.</p>
<p><a href='http://groups.google.com/groups?selm=a05111b14b973d63571a3@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<p><a href='http://groups.google.com/groups?selm=20020805084317.GA24299@strontium.pps.jussieu.fr' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=OF7220C971.8B8F54C5-ON85256C0C.00682E2A@boulder.ibm.com' target='_blank'>groups.google.com</a></p>
<a name='Exceptions'></a><h2>Exceptions</h2>
<p>Dan posted his road map to exception handling. Or rather, he described
the two ops (<code>push</code> and <code>throw</code>) needed to do exception handling, but
punted on what an exception object should look like.</p>
<p>Florian Weimer wondered if it wouldn't be possible to handle exception
objects in the throwing context. Dan reckoned that this could be
problematic, which is why we're not going to do it `at the moment'.</p>
<p>Jerome wondered if we really needed the <code>pushx</code> opcode at all. Tanton
Gibbs disagreed and there was some back and forth about that, and
about whether it made sense to think of a <code>return</code> as an exception
(it does, but only rarely, when you're writing your own control
structures; Damian will explain more later).</p>
<p>Dan also thought that <code>pushx</code> would be necessary, and Jerome
clarified his suggestion. Simon Glover wondered what happened when a
program didn't define an exception handler and was reassured that
there would be some kind of default (probably language specific)
handler in place, and if an exception got past that then Parrot would
handle it itself with a suitably `big fit to STDERR' before dying in a
fit of pique.</p>
<p><a href='http://groups.google.com/groups?selm=a05111b18b97464ad4527@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<p><a href='http://groups.google.com/groups?selm=20020805184917.GA25956@strontium.pps.jussieu.fr' target='_blank'>groups.google.com</a> -- Discussion of
whether <code>pushx</code> is necessary starts here.</p>
<a name='Regex speedup'></a><h2>Regex speedup</h2>
<p>Angel reposted his patch to the regex subsystem, this time with
appropriate diff flags. Brent Dax needed more clarification, which
Angel gave; Dan accepted that, given docs and tests, the patch could
go in. Angel made another patch with docs and tests, although Mike
Lambert then asked for more clarification, and pointed out some issues
with the <code>inline</code> keyword not being standard across all C
compilers. He also wondered if Brent's old 'Tutorial' docs could be
updated and reinstated. Angel responded with more clarification, and a
promise that the tutorial would go in when he'd rewritten it, and
commented that `The previous Rx version had excellent documentation,
so it will take a bit of time to get there.'  I don't think this patch
has been applied yet.</p>
<p><a href='http://groups.google.com/groups?selm=200208060707.51991.afaus@corp.vlex.com' target='_blank'>groups.google.com</a> -- Start here.</p>
<a name='Lexicals and globals assembly question'></a><h2>Lexicals and globals assembly question</h2>
<p>Brian Wheeler has been looking at <code>store_lex</code>, <code>find_lex</code>,
<code>store_global</code> and <code>find_global</code> and pointed out that the <code>store_*</code>
ops seemed to be the wrong way round, since the parrot rule is that
the destination is always the first operand. The response to this can
be summed up in one word: &quot;Oops.&quot; Brian has patched it, and added
tests. Leopold Toetsch fixed things up in Builtins.pm.</p>
<p><a href='http://groups.google.com/groups?selm=1028600242.26459.3.camel@thor' target='_blank'>groups.google.com</a></p>
<a name='Questions about pdd03_calling_conventions.pod'></a><h2>Questions about pdd03_calling_conventions.pod</h2>
<p>Jonathan Sillito asked a few questions about calling conventions, and
noticed that the <code>callcc</code> op appeared to be going the way of all
flesh. Dan answered the questions and remarked that callcc was to be
reinstated and shouldn't have disappeared in the first place. Sean
O'Rourke wondered why, since it could be replaced with calls to
<code>invoke</code> and other cleverness. Dan agreed. So <code>callcc</code> will stay
dead. (The only reason it was on the perch in the first place was
because it'd been <i>nailed</i> there.)</p>
<p><a href='http://groups.google.com/groups?selm=1028660270.5628.48.camel@localhost.localdomain' target='_blank'>groups.google.com</a> -- Start here</p>
<a name='Hash optimisations'></a><h2>Hash optimisations</h2>
<p>Having had a patch to remove a function call from the hash algorithm
accepted, Jason Greene offered a more comprehensive set of hash
optimisations. Dan applied the patch. Nicholas Clark and Steve Fink had a
few questions. Nicholas wondered why a constant had been changed, and
Steve worried about memory use. Dan reckoned that worrying about
memory to the tune of an unsigned int + alignment bytes at the expense
of speed was the wrong trade-off to make. However, the other subthread
had led to a different design which saved the space and only gave a
small performance hit in the less common case. Dan agreed.</p>
<p><a href='http://rt.perl.org/rt2/Ticket/Display.html?id=16032' target='_blank'>rt.perl.org</a></p>
<a name='Various PMC issues'></a><h2>Various PMC issues</h2>
<p>Stephen Rawls is still trying to write <code>tuple.pmc</code>. Which means he's
been nosing around the sources of all the other PMCs, looking at how
they do things, so, he had a bunch of questions, mostly to do with
PerlNums and PerlInts. The answer to many of the questions appears to
be `the problem will go away when we get multimethod dispatch'. Dan is
pouting because he had `wanted to go with a left-side-wins scheme, but
alas correctness has trumped speed...'. Dan has promised details of
Parrot multimethods `soonish'.</p>
<p><a href='http://groups.google.com/groups?selm=20020807132059.72848.qmail@web14502.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=a05111b59b97848ff2ee9@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Never ending story Keys'></a><h2>Never ending story Keys</h2>
<p>Josef wondered where we are with multi keyed access. Tom Hughes, who
has promised to have a go at fixing things wondered if he was waiting
for hell to freeze over. At which point it started `snowing in Texas'
as Dan came through with the design. There was much rejoicing, and a
snowball fight was threatened. Tom had some questions (no surprise
there: when you're the one doing the implementation, there's almost
never enough information). Clarification was provided, as were
supplementary questions, and supplementary answers. As Blur put it so
eloquently: &quot;Woohoo!&quot;</p>
<p><a href='http://groups.google.com/groups?selm=Pine.GSO.4.21.0208071500540.15346-100000@chicken.stacken.kth.se' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=a05111b55b977c7a65606@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Hatchet job on assemble.pl / the fixup table'></a><h2>Hatchet job on assemble.pl / the fixup table</h2>
<p>Brian Wheeler took an axe to the assembler and some associated files
and asked for comments on his plans. Dan liked the sound of it, so
Brian posted a patch. Leopold &quot;How do you pronounce&quot; Toetsch suggested
making it a standalone library so stuff could just <code>use Assembler</code>
instead of calling yet another external program. Sean O'Rourke asked
for a summary of what had changed, and Brian gave him one. (Oo er).</p>
<p><a href='http://groups.google.com/groups?selm=1028779066.11103.19.camel@thor' target='_blank'>groups.google.com</a> -- proposal</p>
<p><a href='http://groups.google.com/groups?selm=1028819598.18442.1.camel@thor' target='_blank'>groups.google.com</a> -- patch</p>
<p><a href='http://groups.google.com/groups?selm=1028832861.16081.19.camel@wombat' target='_blank'>groups.google.com</a> -- summary</p>
<a name='PMC assignment stuff'></a><h2>PMC assignment stuff</h2>
<p>Dan has been a positive goldmine of designs and specs this week. This
time he offered the design for a new PMC assignment opcode. We already
have <code>SET</code>, which copies the pointers and <code>CLONE</code> making a
'full clone', but we also need <code>ASSIGN</code> to `stuff a value from one
PMC to another'. Peter Gibbs made a start on implementation and asked
for some clarification, which was forthcoming, and then supplied a
patch with his implementation, along with tests. Go Peter!</p>
<p><a href='http://groups.google.com/groups?selm=a05111b53b977b35492d3@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<p><a href='http://groups.google.com/groups?selm=rt-16077-33219.1.71584723963818@bugs6.perl.org' target='_blank'>groups.google.com</a></p>
<a name='Status on matrix patch?'></a><h2>Status on matrix patch?</h2>
<p>Josef is worried about what's happening to the matrix patch. Simon
Cozens used this as an opportunity to crack the worst joke yet seen on
any perl6 mailing list, but Josef appears not to have seen the film
and didn't get the joke. Anyhoo, back on the main line of the thread,
the problem seems to be that in order to have things sensibly
arranged, it made sense for Josef to break the <code>.pmc</code> file up into a
couple of .c and .h files, along with <code>matrix.pmc</code>, but there's
currently no scheme for multi-file PMC classes. Dan also thinks that
putting code into the parrot core just to facilitate code sharing
between PMCs is probably not the right answer. This appears to have
opened a can of worms. Dan is searching for a bigger can -- sorry --
designing the infrastructure that this needs.</p>
<p><a href='http://groups.google.com/groups?selm=Pine.GSO.4.21.0208090928370.24176-100000@chicken.stacken.kth.se' target='_blank'>groups.google.com</a> --
Thread starts here.</p>
<p><a href='http://groups.google.com/groups?selm=86n0rwqtec.fsf@squash.oucs.ox.ac.uk' target='_blank'>groups.google.com</a> -- Terrible joke...</p>
<a name='Constant &amp; opcode swap ops'></a><h2>Constant &amp; opcode swap ops</h2>
<p>Dan offered designs to support multiple segment bytecodes, or at least,
to swap in constant tables. Steve Fink wondered if it might be a good
idea to wrap the interpreter in a PMC and use vtable methods to do
constant table manipulations etc. Dan thinks that's a great idea for
introspection, but worries that it'll slow things down if we make the
interpreter itself go through those hoops all the time. Nicholas Clark
also offered a few caveats (`Are you <i>sure</i> you want to do it this
way?', words to strike fear into the heart of any designer I
think). Dan isn't sure.</p>
<a name='Faster assembler'></a><h2>Faster assembler</h2>
<p>Nicholas Clark offered a patch which makes
<code>Assembler::_generate_bytecode</code> faster. By around 1.5%. Dan applied
it. Sean O'Rourke offered more tweaks. Mattia Barbon had a patch which
meant that the tests could just 'use Parrot::Assembler' rather than
call assemble.pl, but the tweaks have outdated it. Dan and Nicholas
asked for the patch anyway because it would make remaking it easier.</p>
<p><a href='http://rt.perl.org/rt2/Ticket/Display.html?id=16114' target='_blank'>rt.perl.org</a></p>
<a name='Perl 6 regexes...'></a><h2>Perl 6 regexes...</h2>
<p>Dan threw down the gauntlet of implementing Perl 6's regexes from
Apocalypse. Sean O'Rourke has apparently already taken it up.
I think we'll be seeing more of this thread next week...</p>
<p><a href='http://groups.google.com/groups?selm=a05111b05b97cecb019c0@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<p>The terribly named thread about different default values of true and
false rumbled on. Damian averred that code which `relies on the poorly
specified standard values of truth and falsehood <i>deserves</i> to
break'. Damian also argues that Perl ought to have a <i>proper</i> boolean
type. After all, it has proper numeric and string types, and that they
should be used by all built ins. (Which does lead me to wonder about
code like <code>0 but true</code>). Chip reckons that the standard values of
truth and falsehood aren't <i>that</i> badly specified, it's not like
they've ever changed since perl 1, though he does agree that a 'real'
boolean would be nice. Elsewhere in the thread, Chip worried about the
scoping of operator definitions and Damian reassured him a bit.</p>
<p><a href='http://groups.google.com/groups?selm=3D4F0363.3050104@conway.org' target='_blank'>groups.google.com</a></p>
<a name='Use of regular expression on non-strings'></a><h2>Use of regular expression on non-strings</h2>
<p>Threads in perl6-language seem to be longer lived than those over in
internals. I wonder why? This was another thread that started last week
and kept on going. David Whipp clarified his original question and
various people responded. Err... I'm not entirely sure how to
summarise this one, and following the threading is a tad tricky
because Mr Whipp's mailer doesn't do the <code>In-Reply-To:</code> thing.</p>
<p><a href='http://groups.google.com/groups?selm=F0DF160193C9D511B7110050DA8B7C24384755@msexchange.intranet.fast-chip.com' target='_blank'>groups.google.com</a>
is probably as good a place as any to start looking.</p>
<a name='Autovivi'></a><h2>Autovivi</h2>
<p>Luke Palmer wondered how autovivification was going to work with
specific reference to <code>print %foo{bar}{baz}</code>. Would <code>%foo{bar}</code>
still be created if it didn't exist? Answer: &quot;NO! Thank ghod!&quot;. Unless
Larry says otherwise.</p>
<p><a href='http://groups.google.com/groups?selm=Pine.LNX.4.33.0208051951001.10849-100000@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='Perl summary for week ending 2002-08-04'></a><h2>Perl summary for week ending 2002-08-04</h2>
<p>See recursion. Miko O'Sullivan queried the throw-away comment that
regexes were now called 'rules' and wondered if the term `regex' would
be going away. It turns out that I wasn't quite accurate, but that
Damian still reckons that `regexes' should be deprecated in favour of
either `rules' or `patterns', at least in his own writing. For some
reason this ended up spinning off into a discussion of regular,
context-free and context-dependent languages and the nitty gritty
details of when an expression was regular or not. Mark J. Reed ended
up posting a fine essay to the list on the differences between the
various types.</p>
<p><a href='http://groups.google.com/groups?selm=97410-22002826122530518@M2W089.mail2web.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=3D503FD2.6020405@conway.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=20020808040500.GB17193@charm.turner.com' target='_blank'>groups.google.com</a> -- Mark's essay.</p>
<a name='while &lt;&gt; { in Perl 6'></a><h2><code>while &lt;&gt; {</code> in Perl 6</h2>
<p>Adam Lopresto wondered if the <code>&lt;while (&lt;</code>) {&gt;&gt; idiom (with appropriate
DWIMmery) would be necessary in Perl 6 since, given a lazy list
implementation, one could probably get by with <code>for &lt;&gt; {</code>. Trey
Harris agreed. So did Larry, sort of. He's leaning towards only having
<code>for &lt;&gt; {...}</code> do implicit topicalisation, <code>while</code> will require
you to be explicit (damn, another spamassassin trigger word...).</p>
<p><a href='http://groups.google.com/groups?selm=200208091745.g79HjnP02082@express.cec.wustl.edu' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=Pine.LNX.4.44.0208091821370.5313-100000@london.wall.org' target='_blank'>groups.google.com</a></p>
<a name='In brief'></a><h1>In brief</h1>
<p>Piers Cawley missed the point about doing copy on write of the entire
stack when doing closuresque things. Various people explained, very
politely that he was wrong. In a moment of selfish editorial wossname,
I'll spare Piers's blushes by omitting the URL.</p>
<p>Josef added a couple of useful ops. Dan applied the patch, but wondered where
the tests were. Josef has, of course, tested the ops, but Dan wants
`Comprehensive tests in <code>t/</code> for everything' so we notice when we
break things later. Nicholas Clark raised the spectre of `The Schwern
with the big stick.' if we failed to meet that testing goal.</p>
<p>Mike Lambert posted the first of his patches which will, eventually,
unify PMCs and buffers.</p>
<p>Steve Fink posted a patch to convert the hashtable from pointer based
to index based, making the GC system happier. Applied.</p>
<p>Angel Faus posted a 'loop discovery' patch for imcc which attempts to
avoid array spilling whilst in an inner loop. This patch was
applied. Then Leopold Toetsch pointed out a few bugs, and Angel posted
another patch, which hasn't been applied yet.</p>
<p>Andy Dougherty sent some patches to eliminate warnings under Solaris
8. Applied.</p>
<p>Jarkko sent in more warnings patches. Applied.</p>
<p>Sean O'Rourke offered a patch to hashes to do deep cloning. Dan asked
him to hold on a sec, adding that if he hadn't addressed the issue
inside a day or to we should nudge him. Dan, consider yourself
heartily nudged.</p>
<p>Peter Gibbs has removed the <code>set_string_unicode</code> and
<code>set_string_other</code> vtable methods, which are, frankly,
unnecessary. Leopold caught <code>perlundef.pmc</code>, which had been missed
from the original purge.</p>
<p>Jonathan Sillito offered a patch to give scratchpads a pointer to
their parent pads, and ended up with a new Scratchpad PMC. Warnock's
Dilemma applies.</p>
<p>Peter Gibbs offers <code>perlscalar.pmc</code>, Aldo Calpini asked a few
questions, and Warnock currently applies.</p>
<p>Daniel Grunblatt announced that the PPC JIT is now working.</p>
<p>Dan noted that there are some size restriction -- we need to make sure
that our chosen INTVAL is at least as big as a pointer. Andy Dougherty
pointed out some possible caveats and noted that his warnings patch
gave some assistance in this area.</p>
<p>Nicholas Clark found a bug in the assembler under perl 5.005_03. Simon
Glover agreed it was a bug, but nobody is quite sure how to fix
it. Nicholas is working on it though.</p>
<p>Boris &quot;Thank heavens for cut and paste&quot; Tschirschwitz wondered if the
headers of the various PDD (Parrot Design Documents) were kept up to
date, and if he could, in general, trust the docs to be accurate. Dan
reckons they should be mostly up to date. Patches are almost certainly
welcome.</p>
<p>In perl6-language, Chris Dutton wondered if we'd be able to create
anonymous classes ( <code>my $foo = class {...}</code> ) in the same way as we
currently create anonymous subs. Personally, I hope so. Chris worries
slightly about <code> my $foo_class $foo_obj = $foo_class.new </code>, but I
think he's getting his compile time and runtime constructs mixed
up. But what do I know?</p>
<p>SpamAssassin marked last weeks summary as spam in some mailboxes. John
Porter suggested that `Maybe people should add SpamAssassin rule that
deducts 5 points if the message contains /leon brocard/ ?'</p>
<a name='Who's who in Perl 6'></a><h1>Who's who in Perl 6</h1>
<ul>
<li><a name='Who are you?'></a>Who are you?</li>
<p>Dave Mitchell. I work for a small UK-based software company.</p>
<li><a name='What do you do for/with Perl 6?'></a>What do you do for/with Perl 6?</li>
<p>I wrote PDD7 (coding standards), then got sidetracked into fixing perl 5
instead. I intend to get more involved in Perl 6 post 5.8.0 release.</p>
<li><a name='Where are you coming from?'></a>Where are you coming from?</li>
<p>Sheffield?</p>
<li><a name='When do you think Perl 6 will be released?'></a>When do you think Perl 6 will be released?</li>
<p>In about 2 years, then ready for production use in a further year.</p>
<li><a name='Why are you doing this?'></a>Why are you doing this?</li>
<p>Because I love Perl and want to contribute to OSS development</p>
<li><a name='You have 5 words. Describe yourself.'></a>You have 5 words. Describe yourself.</li>
<p>Lazy, apathetic, enjoyerofbugfixing, unsufferinggladlyoffools,
rabidsceptic.</p>
<li><a name='Do you have anything to declare?'></a>Do you have anything to declare?</li>
<p>My lack of genius?</p>
</ul>
<a name='Acknowledgements, corrections, threats and funding drives'></a><h1>Acknowledgements, corrections, threats and funding drives</h1>
<p>Nicholas Clark would just like to clarify that, as far as right shifts
of signed integers go, we should offer both arithmetic and logical
right shifts. He doesn't appear to have any preference about which
should be the default.</p>
<p>This summary was again prepared with the aid of GNER tea, supplemented
this week by a ham and cheese toasted sandwich, the toasted sandwich
of the gods (though their bacon and tomato toastie also has its
adherents I remain faithful to good old ham and cheese.)</p>
<p>Thanks are also due to the wonderful Pete Sergeant, and to a certain
person who I'll not mention again (but his favourite colour is orange)
for their excellent proofreading skills. Anything which may have snuck
past them (especially in this paragraph) is, of course, entirely my
fault.</p>
<p>If your name appears in this, or any previous summary and you've still
not sent me your answers to the perl6 questionnaire, please consider
doing so. My &quot;Perl 6 Who's who?&quot; archive hasn't run out yet, but it'd
be good to know that I'd got a good supply to fall back on.</p>
<p>Still no T?iBook, but this week's haul of egoboo is well up there. Many
thanks to the flatterers in <a href='mailto:perl-golf@perl.org.'>perl-golf@perl.org.</a></p>
<p>If you didn't like this summary, write your own. Go on, I dare you. If
you did like it, send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and remember, suitably large
donations will earn you or your company a plug in a future
summary. (You have to let me know though). See last week for
details. And you'll be helping to fund the next generation of Perl,
which will give you the warm fuzzies and a general feeling of virtue
and well being. In the words of Mrs Doyle, &quot;Go on, go on, go on, go
on!&quot;</p>
</div>
